Add #[track_caller] to methods which panic #1442
Conversation
This makes it easier to diagnose problems when the preconidtions of these methods are not met. Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
There was a problem hiding this comment.
The reference uses std::panic::Location::caller. Is it worth doing this too for better error messages?
| #[track_caller] | ||
| fn from_entropy() -> Self { |
There was a problem hiding this comment.
The potential for failure is due to getrandom, so probably this shouldn't track the caller.
|
Also see:
|
I think that's mostly if we wanted to print out the location, or use the location for something else. If we are just panicking anyway, I think just using #[track_caller] is fine, that's what libstd does for things like .unwrap(). |
|
BTW, I was hoping you'd give #1424 a review — not sure if you missed the comment there? |
Whoops, I did miss that. Ill try to take a look sometime this week. |
This is stuff I missed in #1442 Signed-off-by: Joe Richey <joerichey@google.com>
This is stuff I missed in #1442 Signed-off-by: Joe Richey <joerichey@google.com>
This is stuff I missed in #1442 Signed-off-by: Joe Richey <joerichey@google.com>
This is stuff I missed in #1442 Signed-off-by: Joe Richey <joerichey@google.com> Co-authored-by: Diggory Hardy <git@dhardy.name>
Fixes #1437
This makes it easier to diagnose problems when the preconditions of these methods are not met.
I think I found most of the cases where we can panic based on bad user input. Let me know if I missed any.
We don't use
#[track_caller]for the panics originating from failing to initializedthread_rngas this is more of a "global" problem than a "local" problem.